home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
HAM Radio 3.2
/
Ham Radio Version 3.2 (Chestnut CD-ROMs)(1993).ISO
/
packet
/
pk232com
/
pcpakrat.bug
< prev
next >
Wrap
Text File
|
1988-01-12
|
2KB
|
68 lines
January 6, 1987
There is a bug in the latest version (1.06) of the AEA PC Pakratt
program for use with IBM PC or compatible computers. If you attempt
change the packet parameter SQUELCH at the parameter window from
the default value of NEG to POS, the program will abort and give
you the error message:
RS-232 link error - will reinitialize - Press ESC
and after pressing Escape, the program will try to re-establish a
link with the PK-232 and present the message:
Parameter download error
Please refer to your PC-PAKRATT manual.
Program terminating.
Unfortunately, the parameter download error message isn't mentioned
anywhere in the manual.
This bug apparently does not present a problem to the vast majority
of PK-232 users. It need not concern you if:
you have NOT connected the squelch signal line between
your transceiver and the PK-232 (pin 3 of the RADIO 1
and RADIO 2 interface connectors), or
if you have made the connection, lucky enough to own a
transceiver that provides the correct signal sense to
the PK-232 for the proper operation of RF-carrier CSMA
with the program default value of NEG for the SQUELCH
parameter.
The bug is exhibited when the program incorrectly attempts to send
the command SQUELCH POS to the PK-232. With release 25 June 1987
firmware, allowed values for the SQUELCH parameter are ON, OFF, or
NEG. The value POS causes the PK-232 to return an error code to the
program, which then abruptly crashes.
Fortunately, the fix for this bug is simple. It is only necessary
to change the program to send the allowable values for the SQUELCH
parameter to the PK-232. The patch below will replace the program
values of NEG and POS with OFF and ON respectively.
Using the DOS debug utility, enter the following:
debug utilmod.chn
-e 614c 20 4f 4e
-e 6160 4f 46 46
-e 6174 20 4f 4e
-w
-q
After spending a number of hours building some very nice interface
cables, I was frustrated to think that I may of had to modify them
to cope with a program bug. AEA is aware of the problem, but they
have not yet corrected it. I'm glad that I was able to come up with
a reasonable fix, and hope that this information proves useful to
someone else.
See you on the digital modes!
David J. Buress AD4B
Alexandria, VA